开发板 home 分区未挂载排查

一块 ARM 开发板的 /home 目录单独占用一个 20.8G 的 eMMC 分区。某次上电后该分区未自动挂载，数据全部写入 4G 的根分区，df -h 显示根分区使用率达 96%。手动挂载可以成功，但 df -h 显示该分区的文件系统总容量只有 108M，与 20.8G 的分区大小不符。本文记录这次排查的完整过程：分区存在、文件系统也存在，但两者大小不一致，最终通过 resize2fs 在线扩容解决。遇到"分区未挂载"或"挂载后容量与分区大小不符"这类 eMMC、SD 卡问题时，可按本文流程对照排查。

现象

• lsblk 里 mmcblk0p21 存在、容量正常（20.8G），但 MOUNTPOINT 一列为空
• 手动 mount /dev/mmcblk0p21 /home 可以挂载成功，但 df -h 显示该文件系统总容量只有 108M（已用 84K），不是 20.8G

排查过程

第一步：确认分区上有没有文件系统

blkid /dev/mmcblk0p21

有输出（带 TYPE="ext4"）说明文件系统还在，可以直接挂载；没有输出说明分区上没有文件系统，先用 dmesg | grep mmcblk0p21 排除 eMMC 硬件问题，再考虑 mkfs.ext4（会清空整个分区）。本例中 blkid 有输出，直接挂载成功。

第二步：容量对不上

挂载后 df -h 显示总容量只有 108M。分区大小为 20.8G 而文件系统只有 108M，这是两个不同的概念：df 读取的是文件系统元数据中记录的大小，lsblk 读取的是分区表中记录的分区大小。向大分区 dd 一个小文件系统镜像，或 mkfs 时指定了较小的尺寸，都会造成分区大于文件系统的状态。本例中最可能的原因是烧写镜像时向该分区写入了一个 108M 的小文件系统。

修复

扩容文件系统到分区大小

ext4 支持在线扩容，挂载状态下可直接执行，数据无损（当时该文件系统仅使用 84K，基本为空）：

resize2fs /dev/mmcblk0p21

挂到 /home 并确认

umount /dev/mmcblk0p21        # 若当前挂载在别的路径
mount /dev/mmcblk0p21 /home
df -h /home                   # 应显示 20G 左右

开机自动挂载

blkid /dev/mmcblk0p21 取 UUID，在 /etc/fstab 中添加一行（UUID 换成实际值）：

UUID=xxxx-xxxx  /home  ext4  defaults  0  2

mount -a 验证无报错后重启一次，确认开机能自动挂载。

回收根分区空间

/home 挂载新分区后，根分区上旧的 /home 目录被遮盖：内容仍然存在，继续占用根分区的空间。可通过 bind mount（将同一棵目录树挂载到另一个路径）绕过遮盖，访问旧数据：

mkdir -p /mnt/rootfs
mount --bind / /mnt/rootfs
du -sh /mnt/rootfs/home       # 查看旧数据量；需要保留的数据先复制到新 /home
rm -rf /mnt/rootfs/home/*     # 确认无需保留后再删除
umount /mnt/rootfs

要点

• 文件系统大小与分区大小是两个概念：df 读取文件系统元数据，lsblk 读取分区表；向大分区 dd 小镜像会导致文件系统容量小于分区容量
• resize2fs 在线扩容不损失数据，相比重新格式化更简便；该方式仅适用于 ext4，其他文件系统（如 squashfs）只能重新 mkfs
• 挂载的作用是遮盖而非替换：旧目录内容被隐藏，但仍占用磁盘空间；mount --bind 可访问被遮盖的内容
• 排查顺序：先用 blkid 确认分区上存在文件系统，挂载后用 df 核对容量，最后检查 /etc/fstab（UUID 是否匹配）与 dmesg，解决开机未自动挂载的问题